home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1665 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  5.8 KB

  1. Path: newsfeed.internetmci.com!xmission!news
  2. From: tknarr@xmission.com  ( Todd Knarr )
  3. Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.edu,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3
  4. Subject: Re: Hungarian notation
  5. Date: 12 Jan 1996 02:11:27 GMT
  6. Organization: Chaos Central
  7. Message-ID: <4d4g0f$qmr@news.xmission.com>
  8. References: <30C40F77.53B5@swsbbs.com> <30EF0415.6FE1@tus.ssi1.com> <1996Jan7.045815.8676@ohstpy> <4cpb00$nqk@news.xmission.com> <4crm6i$24mi@navajo.gate.net> <4csi2t$gsa@news.xmission.com> <4ctomq$1pi8@hopi.gate.net> <4cvhga$5rn@news.xmission.com> <4d31ne$2m6@hopi.gate.net>
  9. Reply-To: tknarr@xmission.com ( Todd Knarr )
  10. NNTP-Posting-Host: slc5.xmission.com
  11. X-Newsreader: IBM NewsReader/2 v1.2
  12.  
  13. In <4d31ne$2m6@hopi.gate.net>, feathers@gate.net (Michael Feathers) writes:
  14. >Funny enough, even in the absence of HN it seems that there would still
  15. >be a problem.  Someone would look at the declaration of the reference
  16. >and see that "ambiguous" type and could very well be decieved.  Frankly,
  17.  
  18. As I said, the problem comes only when they believe the promise that the
  19. HN prefix makes. If you're going to ignore that promise on all variables,
  20. why bother making it in the first place? Absent the HN prefix, anyone
  21. looking at the code will automatically look back to the declaration to
  22. find the type, and my automatic reflex when I see a pointer or reference
  23. type in C++ is to check the class heirarchy. If I believe the HN prefix,
  24. I don't have a reason to check the declaration, I won't see the reference
  25. typing, and I won't get reminded to check the heirarchy before assuming
  26. that it's really the type claimed. Pointers are more obvious, but HN is
  27. still making a promise that a pointer to Stall is a pointer to Stall and
  28. not a pointer to OfflineStall so the potential for believing the promise
  29. is still there.
  30.  
  31. Leaving the HN off won't guarantee the programmer will check, but at least
  32. it doesn't give him an excuse to cry "But the name *said* it wasn't an
  33. OfflineStall!". It's the same as with misleading comments. The idea of a
  34. comment is to tell you what the code is supposed to be doing without first
  35. having to decipher it in detail. If you have to assume the comments are
  36. wrong and decipher the code in detail anyway, are the comments really
  37. doing any good?
  38.  
  39. >I don't really get the problem.  If your derived Stalls are true 
  40. >specializations of the Stall concept, then there are certain operations 
  41. >which apply to all Stalls and there are operations which apply only to
  42. >specific classes of stalls.  The former should be in the base Stall class
  43. >and the latter in each of the derived classes. 
  44.  
  45. That is in fact the case. The Stall class defines the interface and certain
  46. "normal" behavior, and each subclass alters some portions of that behavior
  47. as needed. The problem comes when someone else comes along to do maintenance
  48. on the code. They know what they want to have happen, the question is what
  49. part of the code do they need to change to make it happen. If they read the
  50. detailed design and roadmap document they'll be fine no matter what, but
  51. if they begin by tracing the code to see where the action they want to
  52. change gets triggered ( easy enough, it's a very straight line to the one
  53. member function that handles that action ) then they'll find at that point
  54. that they are dealing with a reference to a Stall. If they have a reason to
  55. believe that, they would then obviously find that member function in the
  56. Stall class and modify it, neglecting to check the class heirarchy to see
  57. whether at that point that reference could be to some other derived class.
  58.  
  59. >I may be wrong, but do you have services in your base Stall class which 
  60. >would more appropriately be in a derived Stall class only?
  61.  
  62. No, every service can be defined in some sensible way for the base class.
  63. Each subclass then alters some or all the behavior of some services to be
  64. appropriate to the particular type. In some cases the subclass must alter
  65. one part of the service for the whole to make sense, but each subclass
  66. alters a different part. For instance, if a particular subclass has to
  67. answer "Yes" to one or more of three questions, the base class answers
  68. "No" to all three and the subclasses only replace the one or ones that they
  69. need to answer "Yes" to.
  70.  
  71. >There is alway RTTI.  You could query and then downcast, but I've never
  72. >had to do that in practice.
  73.  
  74. I dislike using RTTI for that. It smacks too much of type fields, and I
  75. generally don't need to know the type in the code that uses them. It's
  76. the guy who has to figure out where a change needs to be made, and in
  77. which class, that needs to know.
  78.  
  79. >Truly, however, HN can work with polymorphism as long as the assumptions 
  80. >of polymorphism aren't broken, and the prime assumption is that the methods
  81. >available for base classes have reasonable behavior for all derived classes
  82. >if you choose to pass around base class pointers and references.
  83.  
  84. This speaks to use only. To use a class you only need to know the interface.
  85. However, suppose you have a List class that provides the interface and
  86. subclasses ArrayList and LinkedList that provide the implementation. You
  87. can use them without knowing which one you're dealing with readily enough.
  88. But, if one of them is causing segmentation violations, whoever has to go
  89. in and find and fix the bug bloody well has to know which *exact* class
  90. was being used at the time. If the segv occurred when comparing two Lists,
  91. he needs to know that it was two ArrayLists being compared via references
  92. to the base class or he may wind up trying to fix code that does not contain
  93. any bugs ( a rather frustrating excercise in futility ).
  94.  
  95. --
  96. Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
  97.                                       |  Member, USENET Cabal
  98.  
  99. Seriously, I don't want to die just yet.  I don't care how
  100. good-looking they are, I! don't! want! to! die!"
  101.                                         -- Megazone ( UF1 )
  102.  
  103.